The software industry if often described as no less than chaotic. Furthermore, the present situation in the software industry lacks investment transparency and responsibility to customer/investor. Often, software industry is not possible to guarantee profits.
Furthermore, the software industry is characterized by overtime working personal, since there is no mechanism for enforcement of employees except for working hours. There is no effective mechanism to control employees because there are no objective (unprejudiced) criteria for development time period estimation. As a result, the attraction of profession of programmer and qualification of programmers are being reduced and the industry work quality is being degraded.
The Standish Group International, Inc. is a market research and advisory firm specializing in mission-critical software and electronic commerce. The Standish Group collects information related to software projects successes and failures since 1994 and issues an annual “Chaos Report”. Reference is made to FIG. 1, which drawing graphically illustrates the results of the investigations of the Standish Group for the year 2004: only 29% of software projects have succeeded, while 53% were challenged and 19% failed. Over the years, no positive trend can be recognized. FIG. 2 graphically illustrates the research results presented at the CIO Update site, which graph represents the ratio of positive and negative return of investments (ROIs) of software projects. Curve 20 depicts exponential rise of cost of subsequent new features added to the program. Line 22 depicts money income. Interval 24 represents temporary positive ROI, which positive ROI exists until the costs arise over money income. Interval 26 represents negative ROI, which negative ROI replaces the positive ROI forever.
The CIO Update article further explains that the cause of software projects failures is the exponential growth of the work to be done in order to implement a change in the code of apparently the same complexity.
Reference is made to Wikipedia term “Iterative and Incremental development”, which is defined as a cyclic software development process. Under “Implementation guidelines”, it is described that implementation of the software being developed in an iterative development methodology, includes:                Any difficulty in design, coding and testing a modification should signal the need for redesign or re-coding.        Modifications should fit easily into isolated and easy-to-find modules. If they do not, some redesign is needed.        Modifications to tables should be especially easy to make. If any table modification is not quickly and easily done, redesign is indicated.        Modifications should become easier to make as the iterations progress. If they are not, there is a basic problem such as a design flaw or a proliferation of patches.        Patches should normally be allowed to exist for only one or two iterations. Patches may be necessary to avoid redesigning during an implementation phase.        
Iterative development was initially formulated by James Martin in 1991 as part of his “Rapid Application Development” methodology. But no positive influence over software industry can be observed according to the chaos annual reports of Standish Group.
The citation shows that iterative development generally includes re-design and re-coding, just as the present invention recommends. However, iterative development does not provide clear and strict criteria for the situation when each step should be executed. It is important to notice, that there could not be a guarantee that redesign or re-coding will indeed improve the situation for improvement of which situation the step is taken.
In practice in most cases that redesign or re-coding is never done because the ongoing state a software project is usually unknown and uncontrolled. The situation is described, for example, in US patent application 2006282816, by Chung-yang Chen, which states that one of the most difficult things about project management is unknown ongoing condition, status and quality during process.
The popular Agile methodology was introduced in 2001 and was derived from iterative development. However, the Agile manifesto either does not try to recognize the problem, but rather tries to give recommendations about preferred strategy in a given (chaotic) situation. The recommendations given by Agile methodology discuss what activities may be neglected for the sake of time saving. But the cost of neglecting of activities may easily overwhelm the savings. Problems are just postponed to the later stages.
FIG. 3 schematically exemplifies a common software project design. The software project includes a model 30, which model 30 is broken into model segments 32 after the code began to be written, wherein respective programmers 34 are team members each of which is assigned one model segments 32. Each programmer 34 has respective model segment 32 residing in the mind of the programmer as a respective memorized model segment 36. In the example shown in FIG. 3, programmer 34a is assigned model segment 32a and what is kept in the mind of the programmer is memorized model segment 36a. Likewise, programmer 34b is assigned model segment 32b and what is kept in the mind of the programmer is memorized model segment 36b, and programmer 34c is assigned model segment 32c and what is kept in the mind of the programmer is memorized model segment 36c. 
As a programmer 34 reveals a problem in the respective designed model segment being assigned to the programmer, in most cases, programmer 34 does not formally reports the revealed problem to the team leader, but rather makes some decision on and goes on writing the code. All decisions made by programmers without reporting the problem to the leader of team of programmers are short-term decisions, and the short-term decisions transform the code into a spaghetti code.
As stated by Steve McConnell in “Code Complete” 2-nd edition p. 87, a function-level software model design is always done, though sometimes the design is done unconsciously and poor rather than consciously and well.
It should be noted that it does not matter if the code uses objects and seems to be object-oriented. If the objects are not composed into an integral logical system, the code is deformed into a spaghetti code.
Furthermore, some roots of the current software industry problems can be traced in the history of the industry. Typically the very first programs were designed using workflow diagrams. As the programs grew in size, it became very inconvenient to draw diagrams by pencil (there were no drawing software yet) and then, programmers started to design programs in mind.
As the volume of information to be processed went and grew, the code creation process moved into sub-cortex of the human's brain, because the sub-cortex is actually information processing unit having much higher productivity than the cortex.
The method of unconscious construction of the code worked less or more as long as each program was created by a single programmer. But now, the software industry faces a huge problem: poor communication between programmers and between programmers and other project participants, including customers. Poor communication is now commonly recognized as the major factor of software projects failure, but nobody has provided a practically feasible way how to improve communication between the software project members.
There is therefore a need and it would be advantageous to have a methodology that allows for performing design and coding consciously, and then it becomes realistic to require from programmers to communicate properly.
Object Oriented Programming (OOP) concept is acknowledged as a mainstream technique used for software development but there is no strict definition of what OOP is. Most programmers believe they are object oriented, while really the programmers have no clear idea of what OOP means. Here is a citation from OOP article appearing in Wikipedia: “Attempts to find a consensus definition or theory behind objects have not proven very successful, and often diverge widely.”
The following is a definition which definition is strict enough for the purposes of the present invention: an object is a reflection/representation/abstraction of a single material or abstract or imaginable item one might want to represent in program. An object-oriented program is a program operating with objects. Object-oriented design (OOD) and/or OOP concepts state the following: “one should design his/her software system as a set of interacting objects and then implement the same objects in the code.”
Technically, representation is implemented in object-oriented programming languages as data structure, representing the state of the source item, along with associated set of functions representing the behavior of the source item.
In order to reflect human's ability of abstract thinking, a number of additional technical features are implemented in object-oriented programming languages. The most basic of the features are concepts of class, encapsulation, inheritance and polymorphism. Named pair of data structure layout and set of functions is called class, wherein a data item is called member data of the class and the functions are called member functions of the class. In practice and science we tend to classify items in question. The classification items of the may be hierarchical. The hierarchical classification is implemented in object-oriented programming languages as inheritance. The concept of encapsulation emphasizes the fact that it is preferable, productive and safe to think about object as if the object is black box. Then the concept of object becomes simplification means which simplification means helps to analyze big system in the human's mind. The concept of polymorphism reflects the fact that people are able to recognize some abstract similarities in the behavior of real items belonging to different classes.
In all Object-Oriented languages, objects are instantiated as embodiments of some class. A class must be declared before one or more objects, representing instances of the declared class, can be created. Later in present document, for the sake of brevity, the terms “object” and “class” might be used interchangeably.
Furthermore, nobody exactly knows what actually could be expected from OOP. The truth is that OOP is great simplification means, which simplification means could help analyze large systems and write understandable code, but the “principle of minimal changes” cancels the advantages, promised by OOP.
The principle of minimal changes requires producing of subsequent versions of software system by doing minimal changes in the working code.
Multithreading
For now there is no feasible methodology of writing thread-safe code and all existing recommendation finish with the same sentence that multithreading issue is very difficult even for experts. Experts have no definite methodology as well.
There is a very important term: thread affinity of code and data. The point is that in order to be able to write thread-safe code it is required to be able to answer the following questions:                a) On what specific thread a code (function) is performed, or, in other words, within workflow (route of execution) of which thread the code (function) is performed.        b) What data does the code (function) changes and/or uses for reading.        
Each thread has a purely sequential workflow.
Theoretically, each function might be called within workflow of any thread. Therefore, the same function might be performed several times concurrently on different threads.
Important notion: as it is spoken about object-oriented code, “the same function” means “the same function, called on the same object (instance of the class whose member the function is)”.
The problem of thread unsafety is caused by concurrent usage of the same memory on different threads.
Not only the same function, but also different functions may use the same memory concurrently on different threads.
Reference is made to FIG. 4, which schematically illustrates a traditional technique of multithreaded coding. There are potentially shared memory items annotated as A, B and C, and two threads 40 and 42. Signs 51, 52 and 53 designate segments of code, using memory item A. Signs 61, 62 and 63 designate segments of code, using memory item B, and signs 71 and 72 designate segments of code, using memory item C.
Rectangles 55, 56 and 57 designate critical code sections which code sections, using memory item A, should be locked with the same locking object. Rectangles 65, 66 and 67 designate critical code sections which code sections, using memory item B, should be locked with the same locking object. Rectangles 75 and 76 designate critical code sections which code sections, using memory item C, should be locked with the same locking object.
Besides of just locking of the code, which code uses shared memory items, it is required to provide proper locking granularity (recognize the edges of the code to be locked) and proper critical sections nesting (inverted order of nesting represents potential deadlock).
Furthermore, it is required to plan usage of waiting system calls, because when a shared memory item changes on some thread of execution, other thread(s), interested in that item, should be notified about the change.
The described approach requires tracing of workflow of each thread and recognizing combinations of code fragments which fragments are performed on different threads and the fragments use the same memory. The work of recognition of combinations is the work of exponentially growing complexity.